1. Field of Invention
The present invention relates generally to late binding software objects, and specifically to supporting multiple late binding objects with a same identifier in an operating environment that only supports registration of a single late binding object for each identifier.
2. Background of Invention
Contemporary software development often utilizes late binding. In late binding, external code is associated with a program at run time rather than at compile time. Therefore, late binding allows software developers to change functionality associated with a computer program, without having to change or even have access to the source code.
For example, suppose an accounting software program includes calls to a capital gains object, which contains code to categorize capital gains, and to calculate capital gains tax. Without late binding, in order to change the capital gains object to take advantage of a more robust calculating algorithm, or to reflect changes in the tax law, the software developer would be required to edit the source code of the accounting program, recompile the source code, relink the object code, and distribute a new executable image to all users of the software.
This problem can be solved by making the capital gains object a late binding object, external to the accounting program itself. That way, the accounting software could be programmed such that all calls to the capital gains object will execute code to determine which late binding object is associated with the call, and then to access that object. Therefore, in order to update the capital gains functionality, the developer would need only to modify the capital gains object itself, and to make the new capital gains object available to users of the accounting software. This eliminates the need to edit and recompile the source code for the accounting program. All calls within the unmodified accounting program would then be automatically associated with the updated capital gains object.
One example of late binding is the use of Component Object Module (COM) objects in Microsoft Windows®. COM objects are late binding objects that are programmed according to a published Microsoft standard. The use of COM objects is very widespread within Windows programming. A developer can register a COM object having a specific identifier with the Windows operating system. Other Windows programs can then call the registered COM object through the operating system, by using the identifier. Both Microsoft and other providers of Windows software frequently use COM objects to provide late binding functionality.
One problem with COM objects is that Windows requires each identifier to be uniquely associated with a single COM object. As a result, multiple COM objects cannot be associated with the same identifier. In other words, there is no mechanism within the Windows operating system for associating different programs with different COM objects having the same identifier. All programs that call a COM object with a specific identifier must access the same COM object. If the COM object is updated, all programs will automatically access the updated version.
This can be problematic, because it is often desirable to have multiple versions of a software program installed on the same computer, and these multiple versions might need to access different versions of a given late binding object, such as a COM object. For example, suppose a new version of an accounting program is released, and it uses an updated capital gains object, having the same identifier as the older capital gains object in the previous version of the software. A user might wish to install the updated version of the accounting software on his computer, but at the same time keep the earlier version installed. This could be the case, for example, if the user wanted to test the new version before deleting the old version. Additionally, a user might need to utilize different versions of the accounting program for different purposes, such as personal, business, domestic and foreign accounting. However, because Windows only supports registration of a single COM object for each identifier, for all programs running under the operating system, different versions of the accounting software would not each be able to access separate capital gains objects with this same identifier. Instead, all versions would have to access the same capital gains object. This problem is not limited to Windows and COM objects, but exists wherever an operating system or other type of operating environment (e.g., a middleware environment such as CORBA or SOM) only supports the use of a single late binding object with the same identifier.
This could be prevented by using new late binding object identifiers in each version of the accounting software, but that would require that all calls to all late binding objects be changed in the source code, thereby eliminating the ability to update functionality without recompiling source code of the underlying application, which is a primary advantage of late binding.
Another option would be to make all versions of the software compatible with the same late binding objects, but this would severely limit the ability of developers to introduce varied functionality across software releases. Furthermore, such a requirement would make software testing difficult and expensive.
Another solution would be to require to no more than one version of a software program be installed on a user's machine at any one time, but this is unacceptable from a marketing standpoint to many software vendors.
What is needed is a method, a computer program product and a system that allow using multiple late binding objects with the same identifier in an operating environment that that only supports registration of a single late binding object with the same identifier.